In requesting an operation to be performed by a server being accessed by a user, it is often necessary to confirm the identity of the user before the requested operation, for example, the accessing of an identified user account, can be performed. Traditional authentication methods are generally not suitable for use in computer networks where attackers can monitor network traffic and intercept passwords. The use of a strong authentication method is therefore needed to avoid the interception of sensitive information such as passwords, user IDs, account numbers and the like. The Kerberos system is an authentication system designed to authenticate, without passing the user password over wire, and to enable an exchange of private information securely across an open network.
In general, the Kerberos process includes a ticket granting service (TGS) to assign a unique key or ticket to each user that logs on to the network. The ticket is then used for authentication and per message encryption. The Kerberos system is a distributed authentication service that allows a client running on behalf of a principal or user to prove its identity to a verifier, such as an application server, without sending authentication data (user password) across a network that might allow an attacker or the verifier to subsequently impersonate the principal.
In a Kerberos system, the session ticket issued by TGS contains the session key and the computed encryption algorithm that is to be used by the client and the server for secure communication. In the current implementation of Kerberos protocol, the encryption type (encryption algorithm) that is used for secure data transfer between the client and the server making use of the Kerberos protocol uses, as the encryption type, the first encryption type match between the list of encryption type entries present in the krb5.conf file (Kerberos client configuration file) on the client machine and the list of encryption types (encryption algorithm) supported by the server's Kerberos principal entry present in the KDC database, during the formation of the session ticket by the Ticket Granting Service (TGS), initiated by the client machine.
There is a single Kerberos configuration file (krb5.conf file) on every client machine having the administrator-defined list of available encryption types. The encryption algorithm that will get selected for secure communication between the client and the server will be the same for all users on the client machine. So for example if DES3 is the first entry in the Kerberos configuration file (krb5.conf) on the client machine and if the server supports, for example, DES, DES3 and AES encryption algorithms, then all users on the client machine will have to communicate with the server only in DES3. If one of the users on the client machine wants to communicate in AES (a higher degree of security) while some other user logged on to the same client machine at the same time wants to communicate with DES encryption type (a less secure but possibly a moderately faster encryption type), this can not be accomplished. With the current implementation, both users will have to communicate with DES3 encryption type as it is the first entry in the configuration file. So, even though a server supports both AES and DES, the users are forced to use the DES3 encryption type that is defined as the first encryption type in the Kerberos configuration file (as the first match decides the encryption type to be used between the client and the server).
Thus, there is a need to provide an improved Kerberos system in which users are provided means by which users may select different encryption types from among a plurality of encryption types contained in a Kerberos configuration file.